home *** CD-ROM | disk | FTP | other *** search
- Path: fido.asd.sgi.com!austern
- From: gregor@netcom.com (Greg Colvin)
- Newsgroups: comp.std.c++
- Subject: Re: sample auto_ptr template
- Date: 06 Apr 1996 11:33:51 PST
- Organization: Netcom Online Communications Services (408-241-9760 login: guest)
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <gregorDpFBCt.A5@netcom.com>
- References: <009A04DA6A831C40.49800EAC@ittpub.nl> <4jucle$i41@bmtlh10.bnr.ca>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: Sat, 6 Apr 1996 04:34:05 GMT
- Apparently-To: comp-std-c++@uunet.uu.net
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMWbHIEy4NqrwXLNJAQEDbQH9HBetsC2nmndl/JM9MT7gF0JG3tvuiNWO
- M0HDnFP5t5k6xNz3xKX9LXYMk+GTPwY7bsd6dMngLlc5aamZqtKbGw==
- =nw7g
- Originator: austern@isolde.mti.sgi.com
-
- In article <4jucle$i41@bmtlh10.bnr.ca> "john (j.d.) hickin" <hickin@bnr.ca> writes:
- ...
- >The January DWP continues to say that auto_ptr provides strict ownership
- >semantics [20.4.5 Template class auto_ptr]:
- >
- >2 The auto_ptr provides a semantics of strict ownership. An object may
- > be safely pointed to by only one auto_ptr, so copying an auto_ptr
- > copies the pointer and transfers ownership to the destination.
- >
- >The implementation you have quoted does not contradict the above statement.
- >The January version of auto_ptr had the owner's stored pointer set to 0 so
- >that dereferencing under such conditions was not allowed:
- >
- >X& operator*() const;
- >
- > Requires:
- > get() != 0
- > Returns:
- > *get()
- >
- >A simple amendment to the DWP, perhaps already in the works, is all we require:
- >
- To my knowledge this is not "already in the works".
- >
- >X& operator*() const;
- >
- > Requires:
- > owner == true
- > Returns:
- > *get()
- >
- >With change, dereferencing will, as before, be undefined when ownership is
- >not held.
-
- Please remember that auto_ptr is designed to make sure that pointers are
- deleted when exceptions are thrown, not to be sure that already deleted
- pointers are not misused. The semantics of auto_ptr are intentionally
- "as close as possible" to ordinary pointers: if you use a pointer that is
- already deleted the behaviour is undefined, and the same for auto_ptr; if you
- use a pointer that is owned by another object (i.e. will be deleted by that
- objects destructor) the behaviour is well defined as long as the pointer
- remains valid, and the same for auto_ptr; you cannot tell at runtime whether
- a pointer is valid, and the same for auto_ptr.
-
- What you can do is design your code so that you know who owns each object when.
- The auto_ptr template can help you implement such designs safely. If you
- cannot design your code to work with auto_ptr you probably need garbage
- collection of some form.
-
- I do not forsee any fundamental changes in the auto_ptr design: its too late
- and has taken too much work to get it where it is today. The important issues
- are whether it is completely and correctly specified, and whether any
- necessary features are missing. In particular:
- * Should auto_ptr have an operator-> ? A proposal to add one was nearly
- accepted at Santa Cruz, but was withdrawn when the prerequisite extension
- failed.
- * Should auto_ptr have an operator== ?
- * Should any of the auto_ptr functions have exception specifications?
- * Many of the requirements can be diagnosed at compile-time but are only
- specified to produce undefined behavior at run-time. Should we tighten the
- specification? If so, how?
-
- Greg Colvin
- gregor@netcom.com
- ---
- [ comp.std.c++ is moderated. To submit articles: Try just posting with your
- newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
- comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
- Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-